Day 2 寫 User Journey 時，我提過一個想法：

以前 PM 想的是：怎麼讓 User 少走一步；Agent 時代更值得問的是：這一步，為什麼還需要 User 自己走？

接著幾篇，我陸續拆了 Form、Search、Category。

但拆到這裡，我突然發現一個更實際的 PM 問題：

如果 User 不再按照我們預先設計好的 Journey 一步一步走，那 UI 到底要怎麼設計？

這可能才是 Generative UI 真正有意思的地方。

做了很多年 PM，我其實很習慣「先畫 Page」

以前做產品，我很自然會把一個功能拆成：

Homepage
   ↓
List
   ↓
Detail
   ↓
Form
   ↓
Confirmation

PRD 也是跟著 Page 寫：

• 這頁有哪些 Component？
• Button 點下去去哪？
• 哪些欄位必填？
• Error 怎麼顯示？
• 下一頁是什麼？

因為我們預設：

產品團隊可以事先定義 User 會走哪條路。

但假設今天我做的是一個 AI Analytics Product。

User 進來第一句是：

「幫我看看這個月 Conversion 為什麼掉了。」

System 可能先顯示：

KPI Summary
+
Trend Chart
+
異常 Channel

User 接著問：

「哪個渠道掉最多？」

畫面變成：

Channel Breakdown
+
Comparison Table

接著他又說：

「只看新 User。」

畫面再次變成：

Filtered Trend
+
Segment Table

問題來了。

這條 Journey 要怎麼事先畫成 Page A → Page B → Page C？

其實很難。

因為下一步取決於 User 此刻想追問什麼。

從 Page Flow，變成 Task State

這讓我覺得，AI Product 可能需要另一種 UI 思考方式。

以前我們先問：

User 現在在哪一頁？

但未來有些場景，更重要的問題可能是：

User 現在正在完成什麼 Task？Task 進行到哪個 State？

例如分析 Conversion：

Task = Diagnose Conversion Drop

State 1
發現異常
↓
Trend Chart

State 2
定位來源
↓
Channel Breakdown

State 3
比較差異
↓
Comparison Table

State 4
深入 Segment
↓
Segment Analysis

這時候 UI 不再完全由「Page」決定。

而是由 Task State 決定。

Generative UI 不是叫 AI 現場畫網頁

第一次聽到 Generative UI，很容易想成：

User 說一句話，LLM 現場寫 HTML / CSS，生成一個全新的 UI。

技術上當然可以。

但如果真的要做到 Production，我反而不太希望 AI 每次自由發揮。

因為 UI 背後還有很多產品限制：

• Design System
• Accessibility
• Tracking
• Permission
• Business Rule
• Security
• QA

更實際的方法可能是：

產品團隊先準備一套 AI 可以使用的 Component。

例如：

Component Registry

KPI Card
Trend Chart
Result List
Comparison Table
Calendar
Map
Form
Confirmation
Payment

AI 不需要自己「發明」一個 Table。

它要判斷的是：

現在這個 Task State，最適合使用哪一個 Component？

這件事就開始變得很 Product。

一個 Component，至少要定義三件事

假設 AI 判斷現在應該顯示 Comparison Table。

System 還需要知道：

Component
= ComparisonTable

Data
= Channel / CVR / Change / Traffic

Actions
= Filter / Drill Down / Compare

所以 Generative UI 真正動態產生的，不一定是一個「網頁」。

更像是一份 UI Schema：

Task
 ↓
State
 ↓
Component
 ↓
Data
 ↓
Action

例如：

Task = 分析 Conversion 下跌

State = 比較 Channel

Component = Comparison Table

Data = Channel Metrics

Action = Filter / Drill Down

前端只需要按照這份 Schema，把既有 Component Render 出來。

這和「讓 AI 自由畫 UI」是兩件完全不同的事。

但 AI 不能想叫什麼 Component 就叫什麼

再往下一層，就會遇到 PM 很熟悉的東西：

Business Rule。

例如：

查看資料
→ Chart / Table 可以動態產生

修改資料
→ 必須進入 Edit State

送出申請
→ 必須顯示 Confirmation

付款
→ 必須使用固定 Payment Flow

所以完整一點，其實會變成：

User Task
    ↓
Current State
    ↓
Allowed Components
    ↓
Data + Actions
    ↓
Guardrails
    ↓
Render UI

也就是說，AI 不是擁有無限 UI 自由。

PM 仍然要定義：

在什麼 State 下，AI 有權提供哪些 Interaction？

還有一件很重要的事：Fallback

如果 AI 判斷不出下一步呢？

這也是我覺得很多 AI Demo 很漂亮，但真的做 Product 一定會遇到的問題。

例如 User 的需求資訊不足：

資訊不足
→ Ask User

沒有適合的 Component：

Component 不支援
→ Standard UI

牽涉高風險操作：

High-risk Action
→ Fixed Flow

AI 不確定 User 要比較還是直接執行：

Low Confidence
→ Clarify

所以真正成熟的 Generative UI，很可能不是：

所有 UI 都是 Dynamic。

而是：

Dynamic UI + Fixed UI + Conversation

三者一起存在。

那 PM 的 PRD 要怎麼寫？

這是我覺得最值得重新思考的地方。

以前我可能按照 Page 寫：

Page 1
- Component
- Button
- Validation

Page 2
- Component
- Button
- Validation

但如果今天做 Task-driven UI，我可能會開始定義：

這時候 PM 設計的已經不只是一張 Wireframe。

而是一套：

System 如何根據 User Task，決定下一個 Interaction 的規則。

Day 7｜我們可能不再只是在設計 Page

回頭看前六篇，我一直在拆一些以前做產品很自然的假設：

User 不一定要自己走完整 Journey。

不一定要自己把需求翻譯成 System 的 Structure。

不一定要猜 Keyword。

也不一定要理解 System 的 Category。

那下一個問題自然就是：

如果 Journey 本身都開始變得 Dynamic，我們還能不能只用固定 Page 思考產品？

我覺得答案不是「Page 會消失」。

Dashboard、設定頁、歷史紀錄、高頻固定操作，Stable UI 仍然非常有效率。

真正改變的是：

以前我們通常是：

Page
 ↓
Component
 ↓
User 找到功能
 ↓
完成 Task

未來有些 AI Product 可能反過來：

User Task
 ↓
Current State
 ↓
Allowed Component
 ↓
Data + Action
 ↓
完成 Task

Product Principle

不要先決定 Page，再把 Task 塞進去；先定義 Task、State 與 Action，再決定這一步需要什麼 UI。

所以我現在理解的 Generative UI，不是「AI 幫我畫介面」。

而是：

以前 PM 設計 User 要走哪幾個 Page；未來我們可能更需要設計，在不同 Task State 下，System 應該提供什麼 Interaction。

這才是我覺得 Generative UI 真正值得 PM 關注的地方。